初级知识
1、进程间通信
- 同步请求的响应风格
- 异步请求的事件驱动风格
请求响应的风格最常见和传统的方式就是构建为RESTful 服务，但是，使用RESTful 服务来实现进程间通信显得过于笨重、低效并且容易出错。
2、进程间通信技术的演进
- 传统的RPC：
早期有一些流行的RPC实现，比如通用对象请求代理体系结构CORBA和 Java 的远程调用(remot method invocation, RMI)；但是，他们的实现极其复杂，因为他们是构建在TCP这样的通信协议之上。
- SOAP
鉴于CORBA等传统RPC实现的局限性，简单对象访问协议（SOAP）就产生了，SOAP是面向服务的架构（SOA）中的标准通信技术，能够基于任意的底层通信协议进行通信，其中最常用的就是HTTP。
- RESTFul
描述性状态迁移 (REST) 是面向资源的架构的基础，在这种架构中，需要将分布式应用程序建模为资源集合，访问这些资源的客户端可以变更这些资源的状态（创建、修改、删除）。RUST 的通用实现是 HTTP。
随着微服务的数量及其网络交互的激增，RESTFul 服务已经无法慢煮现代化的需求了，下面介绍 3 个主要的局限性：
- 基于文本的低效消息协议：RESTFul 服务建立在基于文本的传输协议之上，并且会使用人类可读的文本格式，如 JSON。
- 应用程序之间缺乏强类型接口：越来越多的服务要通过网络进行交互，而且这些服务使用完全不同的语言来构建，缺乏明确定义和强类型的服务接口成了使用RESTFul 服务的主要障碍。
- REST 架构风格难以强制实施：REST 架构风格有很多好的实践，只有遵循这些实践，才能构建出真正的 RESTFul 服务；但是，由于没有作为实现协议（如：HTTP）的一部分强制要求，因此，在实践阶段，这些实践难以实施。
3、gRPC 的起源
来源于 Google 的 Stubby 的通用 RPC 框架。2015 年 Google 发布了 Stubby 的社区版本 gRPC 框架，并捐献给了 CNCF 社区。
4、gRPC 的优势
- 提供高效的进程间通信。
- gRPC 没有使用类似 JSON 、 XML 之类的文本传输协议，而是采用自定义的
protocol buffers的二进制协议。- gRPC 在 HTTP/2 上实现了 protocol buffers 的协议。
- 具有简单且定义良好的服务接口和模式
gRPC 为应用提供了必须先定义接口，才能去处理细节的要求，gRPC 为应用提供了简单但一致，可靠且可扩展的应用程序。
解决了类似 REST 模式需要遵循好的架构风格实践，才能构建出真正的 RESTFul 服务，但是 gRPC 自带类似的好的架构风格。
- 属于强类型
通过定义应用服务之间通信所使用的类型，对于其所产生的大多数运行时错误和互操作错误，可以通过静态类型来克服。
- 支持多语言
gRPC 支持多语言，基于 protocol buffers 定义的服务时语言中立的。
- 支持双工流
gRPC 客户端和服务端都提供了对流的原生支持。
- 具备内置的商业化特性
gRPC 提供了商业化特性的内置支持，如认证、加密、弹性、元数据交换、压缩、负载均衡、服务发现等。
- 与云原生系统进行了集成
gRPC 是 CNCF 的一部分，大多数框架和技术都对 gRPC 提供了原生的支持。
同时提供了丰富的应用性能监控工具。如 metrics、tracing、logging。
5、gRPC 的劣势
- gRPC 不太适合面向外部的服务
gRPC 服务具有契约精神、强类型等特点，会限制暴露外部服务的灵活性，同时消费者的控制权会削弱很多。gRPC 网关是克服该问题的解决方案。
- 大的服务变更是复杂的开发流程
gRPC 服务出现变更，需要重新生成客户端和服务端代码。
- gRPC 系统相对较小
与 REST 和 HTTP 等协议相比，gRPC 的生态系统相对较小。